Process and apparatus for sharing inline caches

ABSTRACT

A technique for dynamic dispatch involves adapting a method at a dispatch point to reference a state cache. State of the state cache may be associated with an object type and a method signature. When a method is adapted at the dispatch point to reference a state cache, the reference is to a state cache associated with a state that matches the method signature and the object type of the object dispatched upon. The state cache may be shared among multiple methods with similar associated states to reduce memory requirements.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.11/100,985, filed Apr. 6, 2005, which is a Continuation of U.S. patentapplication Ser. No. 10/991,444, filed Nov. 17, 2004, which is aContinuation of U.S. patent application Ser. No. 10/016,794, filed Oct.29, 2001, which issued as U.S. Pat. No. 6,964,039 on Nov. 8, 2005, andwhich claims priority from U.S. Provisional Patent Application No.60/255,096, filed Dec. 13, 2000, and U.S. Provisional Patent ApplicationNo. 60/555,774, filed Mar. 23, 2004, and U.S. patent application Ser.No. 11/112,967, filed Apr. 22, 2005, all of which are being incorporatedherein.

BACKGROUND

The present invention relates to digital processing systems. Morespecifically, the invention relates to dynamic dispatch in digitalprocessing systems.

Objects, in object-oriented systems, are data structures thatencapsulate data and methods that operate on that data. Classes definetypes of objects. Objects are instances of classes. Methods defineactions the class can perform. Classes can be organized into a hierarchythat includes a parent class at the root. Children of the parent classmay inherit methods and data from the parent, redefine methods and data,or introduce new methods and data. The hierarchy can grow to arbitrarycomplexity. Methods may be distinguished by using a method signaturethat includes the combination of the method's name and the number, type,and order of parameters. The method signature may also include, forexample, a visibility modifier (e.g., public, private, protected), areturn type, a throws clause, or some other value. To invoke a method, amessage is sent to an object, which selects the method to execute. Themethod address may be found at runtime through a technique known asdynamic dispatch. Dynamic dispatching typically entails extracting thedata type (class) of the object and mapping the method signature to amethod address. The inheritance property of classes occasionally makesmethod-lookup somewhat complicated. If a method-lookup fails, themethod-lookup is repeated at the parent of the object's class,continuing up the class hierarchy until the method-lookup succeeds orthe root of the hierarchy is reached.

Inline caching of method addresses is first described by Deutsch andShiffman in “Efficient Implementation of the Smalltalk-80 System,”Conference Record of the Eleventh Annual ACM Symposium on Principles ofProgramming Languages, pp. 297-302, Salt Lake City, Utah, 1984, which isincorporated herein by reference in its entirety. In accordance with theinline caching technique, when the method-lookup succeeds, a direct callto the class's method may be written into computer code at the dispatchpoint (e.g., the point from which the method call was made). Subsequentmethod calls may be more efficient since method-lookup can be avoided aslong as the objects dispatched upon have the same type. Unfortunately,cache size adversely impacts the memory requirements of programs.

Dynamic dispatching is a process of invoking a method on an object,where the method address is determined (deterministically) at runtime bythe signature of the method and dynamic type (e.g., class) of theobject. Once the method is known, computer code associated with thecalled method may be written into the computer code at the dispatchpoint. Subsequent invocations of the method are more efficient becausethe computer code associated with the method is at the dispatch point(inline caching). However, this efficiency comes at the expense ofincreased memory usage.

SUMMARY

A technique for optimizing dynamic dispatch in object oriented systemsincludes inline caching. In one embodiment of the invention, an inlinecache includes an inline reference to a called method. The inlinereference may be direct or indirect. For example, the inline referencemay be directed to a cache state. The cache state may include the calledmethod address and the prerequisite type used for cache validation. Inan alternative embodiment, the cache state may itself include an inlinecache.

The memory requirements of the inline reference and the cache state maynot be significantly less than the memory requirements associated withan inline cache (and could even be more). However, if multiple cachestates share certain characteristics, such as, for example, identicalcached method addresses and prerequisite types, each inline referencecan be directed to the same cache state. Assuming the number of distinctcache states is less than the number of distinct dispatch points, theuse of an inline reference should reduce memory requirements.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated in the figures. However,the embodiments and figures are illustrative rather than limiting; theyprovide examples of the invention.

FIGS. 1A, 1B, and 1C depict diagrams intended to illustrate adapting amethod to include an inline reference to a cache state according to anembodiment;

FIG. 2 depicts a conceptual view of calling methods and called methodsaccording to an embodiment;

FIGS. 3A and 3B depict diagrams intended to illustrate method validationaccording to an embodiment.

FIG. 4 depicts a flowchart of a process according to an embodiment;

FIG. 5 depicts a flowchart of a process according to another embodiment;

FIGS. 6A, 6B, and 6C depict diagrams intended to illustrate adapting amethod to include an inline reference to a cache state according toanother embodiment;

FIG. 7 depicts a networked system for use in an embodiment; and

FIG. 8 depicts a computer system for use in the system of FIG. 7.

DETAILED DESCRIPTION OF EMBODIMENTS

FIGS. 1A to 1C depict diagrams intended to illustrate adapting a methodto include an inline reference to a cache state according to oneembodiment. FIG. 1A depicts a method 162 that includes computer code 164associated with a method call to a method 166. It should be noted thatthis association may be via dynamic dispatch, rather than a fixed callto the method 166. The method 162 is labeled “foo,” which is a commonlyascribed name for methods, functions, procedures, routines, etc. in theart of computer programming. The method 166 is labeled “bar,” which isanother commonly ascribed name for methods et al. The computer code 164associated with the method call to the method 166 may be compiled duringcompile time (turning the computer code into, for example, a binaryfile). The computer code could also be interpreted at runtime. For thesake of illustrative simplicity, the computer code 164 is referred to as“computer code” regardless of any compiling, interpreting, or othermodifications that may be taken to change the computer code from oneform to another.

In operation, when the method 162 executes commands associated with thecomputer code 164 to call the method 166, the point at which the method162 calls the method 166 may be referred to as a dispatch point. Thedispatch point is represented in FIG. 1A as the beginning point of thearrow pointing from the method 162 to the method 166. The starting pointof the method 166, represented in FIG. 1A as the ending point of thearrow pointing from the method 162 to the method 166, may be referred toas an enter point.

In operation, the method 166, once called, executes one or morecommands. When the method 166 is done executing, the method 166 passescontrol back to the calling method 162. The point at which the method166 finishes may be referred to as an exit point. The exit point isrepresented in FIG. 1A as the beginning point of the arrow pointing fromthe method 166 to the method 162. There may be multiple potential exitpoints in the method 166 (not shown) and there may be one or more callsto additional methods (not shown).

In an embodiment, a state acquisition engine 168 intercepts the methodcall from the method 162 to the method 166. Method-call interception(MCI) is a well-known technique for facilitating runtime adaptation forobject-oriented software systems. Since the technique is well-known, MCIis not described in detail herein.

The state acquisition engine 168 determines state information, which mayinclude, for example, object data, method data, and other data. In anembodiment, the other data may include data associated with environmentvariables or other parameters. The state acquisition engine 168 mayperform method-lookup using the method signature at the dispatch point164 and the type of object dispatched upon to find a method address.

Calls from the method 162 to the method 166 may be local. For example,methods 162 and 166 may be stored locally in non-volatile storage ormemory. In an alternative, calls from the method 162 may extend from aremote computer location to or from, for example, a server computeracross a LAN or other network.

FIG. 1B is intended to illustrate state information 170. For exemplarypurposes, the state information 170 includes object data and methoddata. The object data may include, for example, the object type of theobject dispatched upon. The method data may include, for example, themethod signature at the dispatch point (e.g., at computer code 164).

While there is no specific requirement as to the format of the stateinformation 170, the state information should be sufficient to map themethod signature for the object type of the object dispatched upon to amethod address. Advantageously, this can make method-lookup unnecessaryfor subsequent method calls, so long as the state information remainsvalid. In an embodiment, the object type may be referred to asassociated with the method 166. The method 166 may or may not beencapsulated within an object having the object type with which themethod 166 is associated. In another embodiment, the method 166 may ormay not be inherited by the object having the object type. In anotherembodiment, the method 162 could also be associated with the objecttype.

FIG. 1C is intended to illustrate how the calling method (method 162) isadapted to take advantage of the state information. The method 162 isadapted by replacing the computer code 164 with an inline reference 172.The inline reference 172 may be referred to as an inline cache, but, inan embodiment, the inline cache includes only the inline reference to acache state 174.

The cache state 174 calls the method 166. After the method 162 isadapted, the inline reference 172 may be referred to as the dispatchpoint for the method 162. The enter and exit points of the method 166are unchanged. The cache state 174 is interposed between the dispatchpoint of the method 162 and the enter point of the method 166.

Data from the cache state 174 could be incorporated into the method 162as an inline cache. However, in an object-oriented system, the number ofcache states is typically less than the total number of dispatch points.Accordingly, if data from each of the cache states is written into eachmethod at each of the dispatch points, memory resources must beallocated for this purpose. An inline reference to a shared cache statecan ameliorate these memory resource requirements.

FIG. 2 depicts a conceptual view of calling methods (the methods 162)and called methods (the methods 166) according to an embodiment. In FIG.2, dashed boxes represent objects 176 and 178, which may respectivelyencapsulate the methods 162 and 166. In an alternative embodiment, theobjects 176 and 178 do not encapsulate the methods 162 and 166. Thedashed boxes are dashed so as to illustrate an association without toostrongly implying that the objects 176 and 178 must actually encapsulatethe methods 162 and 166.

In the example of FIG. 2, methods 162 may include inline references thatare directed to an appropriate cache state. Though the methods 166 mayor may not initially have identical method signatures, the inlinereferences 172-1 and 172-2 are different because the state information,presumably, indicated that the objects dispatched upon were of differenttypes. As described with reference to FIGS. 1A to 1C, cache states maydiffer depending upon, for example, method signature and the type ofobject dispatched upon.

In the example of FIG. 2, for illustrative purposes, the objects 178-1and 178-2 are assumed to be of different types. Accordingly, the inlinereference 172-1 is directed to a state cache 174-1 for an object typeassociated with the object 178-1. Similarly, the inline reference 172-2is directed to a state cache 174-2 for an object type associated withthe object 178-2.

In operation, when a method 162 reaches the dispatch point, the inlinereference directs the method 162 to the appropriate cache state. Sincethe computer code at the dispatch point has already been adapted todirect the method 162 to the appropriate cache state, no method-lookupis required at the dispatch point.

In an embodiment, the object dispatched upon may change. In thisembodiment, some form of method validation may be conducted beforeinvoking the method 166. Method validation may, for example, includechecking the object dispatched upon to ensure that the object type isthe same as the object type associated with the cache state. If theobject type of the object dispatched upon and the object type associatedwith the cache state are different, the inline reference may be changedto reference a more appropriate cache state. If, on the other hand, theobject type of the object dispatched upon and the object type associatedwith the cache state match, then the method 166 can be invoked without amethod lookup.

FIGS. 3A and 3B depict diagrams intended to illustrate method validationaccording to an embodiment. FIG. 3A is similar to FIG. 1C, but a methodvalidation engine 180 and a hash table 182, which may be a global hashtable, are coupled to the cache state 174. In an embodiment, the stateof the object dispatched upon may be different during a first methodcall and a second method call. Accordingly, it may be necessary todetermine whether state has changed.

In an embodiment, in operation the method validation engine 180 checksthe cache state 174 each time a method call is initiated from thedispatch point of a calling method 162. For example, the methodvalidation engine 180 may check the object type of the object dispatchedupon and compare the object type to the object type associated with thecache state 174. If the object types match then, at least in thisexample, the method is validated and the called method 166 is invokedfrom the cache state 174. If the object types do not match, then themethod call is not validated.

In this embodiment, when the method validation engine 180 determinesthat a method call is not validated, the method validation engine 180may consult the hash table 182 to find a cache state that is valid forthe method call. Cache states may be represented as entries in the hashtable 182. The hash code of the hash table 182 may be a function of amethod signature and object type. The method validation engine 180 candetermine the method signature from, for example, the method call fromthe method 162.

In an embodiment, the method validation engine 180 can determine objecttype from, for example, the object dispatched upon. Accordingly, themethod validation engine 180 can calculate the hash code and use thehash code to obtain a valid mapping of the method signature and theobject type to a target cache state, if the target cache state exists inthe hash table 182. If the method validation engine 180 cannot determinethe target cache state using, for example, the hash table 182, then anew cache state may be created in a manner similar to that describedwith reference to FIGS. 1A to 1C.

When the method validation engine 180 knows a valid cache state by, forexample, finding the valid cache state in the hash table 182 or bycreating a new cache state, the inline reference 172 can be changed toreference the valid cache state. FIG. 3B is intended to illustrate theinline reference 172 referencing a new cache state 184.

As illustrated in FIG. 3B, the inline reference 172 is directed to thenew cache state 184. The new cache state 184 is associated with a newmethod 186. In an embodiment, the method 166 and the new method 186 maybe associated with similar object types. In another embodiment, themethod 166 and the new method 186 may be similar methods.

In an embodiment, when a cache state has no methods pointing to it, thecache state may be deleted. For example, if the inline reference 172 inFIG. 3A was the only pointer to the cache state 174, when the inlinereference 172 is redirected to the cache state 184 in FIG. 3B, a cleanupprocedure may be executed to cleanup or delete the cache state 174. If,on the other hand, other inline references (not shown) remain pointedtoward the cache state 174, the cache state 174 would not, in thisembodiment, be deleted. In an alternative, cleanup may include removingcaches that meet certain criteria.

FIG. 4 depicts a flowchart of a process according to an embodiment. Theflowchart is intended to illustrate instantiation of an object andsubsequent runtime adaptation of a method associated with the object.This process and other processes are depicted as serially arrangedmodules. However, modules of the processes may be reordered, or arrangedfor parallel execution as appropriate.

In this embodiment, the flowchart starts at optional module 202 withinstantiating an object, wherein the instance of the object includes afirst method having a dispatch point to a second method. The object maybe instantiated from a class. The class from which the object isinstantiated may determine the object type associated with the object.In an embodiment, the instantiation of the object is optional. Forexample, the first method may or may not be included in an instantiatedobject.

In the example of FIG. 4, the flowchart continues at module 204 withinvoking the first method and at module 206 with calling the secondmethod at the dispatch point. The flowchart continues at module 208 withintercepting the method call to the second method and at module 210 withdetermining state. The method-call interception (MCI) may be for thepurposes of determining state.

In an embodiment, state may include an object type associated with thesecond method. In another embodiment, the object type may be associatedwith the object encapsulating the first method. In another embodiment,the object type may be associated with an object to which a method callis directed. In another embodiment, the object type may be associatedwith an object from which the method call is derived.

In addition, the state may include a method signature associated withthe method-call. In an embodiment, the method signature may bedetermined from the first method. For example, the first method mayinclude computer code intended to invoke the second method that includesa method name, method parameters, and defines types for the parameters.This data may be used to determine a method signature.

In this embodiment, the flowchart ends at module 212 with adapting thefirst method to include at the dispatch point an inline reference to astate cache associated with the determined state.

FIG. 5 depicts a flowchart of a process according to an embodiment. FIG.5 is intended to illustrate invocation of the second method after thefirst method has been adapted as described, for example, with referenceto FIG. 4.

In this embodiment, the flowchart begins at module 214 with invoking afirst method that includes an inline cache pointing toward a cachestate. In an embodiment, the inline cache may include only an inlinereference directed to the cache state. In an alternative embodiment, theinline cache may include, for example, an inline reference directed tothe cache state.

In this embodiment, the flowchart continues at module 216 with followingthe inline cache to the cache state. Following the inline cache mayinvolve, for example, following an inline reference.

In this embodiment, the flowchart continues at module 218 withperforming method validation to ensure that state associated with thecache state is valid. Performing method validation is not necessary ifstate does not change. However, it is possible that state will changebetween the time the method call is made a first time (and state iscached) and the time the method call is made a second time. For thepurposes of example in FIG. 5, it is assumed that the cache state isvalid.

In this embodiment, the flowchart ends at module 220 with invoking asecond method from the cache state. The cache state may make a methodcall to the second method. The cache state may include a methodsignature associated with the second method for, for example, an objecttype. The object type associated with the cache state may be similar tothe object type associated with the second method. In an embodiment, theobject types are associated with objects instantiated from identicalclasses.

In another embodiment, the object types are associated with objectsinstantiated from related classes. For example, a first class may be aparent that encapsulates the second method and the second class may be achild that inherits the second method. When object types are referred toas being “similar,” this is intended to mean the object types areassociated with either identical classes or related classes. In anembodiment where the object types are always associated with identicalclasses, the object types may still be referred to as similar.

In another embodiment, the cache state may include an inline cache thathas computer code associated with the second method, as described withreference to FIGS. 6A to 6C. FIGS. 6A to 6C depict diagrams intended toillustrate adapting a method to include an inline reference to a cachestate according to an embodiment. FIGS. 6A and 6B are similar to FIGS.1A and 1B, described previously, so a description of FIGS. 6A and 6B hasbeen omitted.

FIG. 6C is intended to illustrate how the calling method (method 162) isadapted to take advantage of the cached state information. The method162 is adapted by replacing the computer code 164 with an inlinereference 172 to the cache state 174. The cache state 174 includes stateinformation and an inline cache 190. The inline cache 190 may includecomputer code associated with the second method 166. The cache state 174may invoke the second method 166 by executing the computer code includedin the inline cache 190.

The following description of FIGS. 7 and 8 is intended to provide anoverview of computer hardware and other operating components suitablefor performing the methods of the invention described herein, but is notintended to limit the applicable environments. Similarly, the computerhardware and other operating components may be suitable as part of theapparatuses of the invention described herein. The invention can bepracticed with other computer system configurations, including hand-helddevices, multiprocessor systems, microprocessor-based or programmableconsumer electronics, network PCs, minicomputers, mainframe computers,and the like. The invention can also be practiced in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network.

FIG. 7 depicts a networked system 700 that includes several computersystems coupled together through a network 702, such as the Internet.The term “Internet” as used herein refers to a network of networks whichuses certain protocols, such as the TCP/IP protocol, and possibly otherprotocols such as the hypertext transfer protocol (HTTP) for hypertextmarkup language (HTML) documents that make up the World Wide Web (theweb). The physical connections of the Internet and the protocols andcommunication procedures of the Internet are well known to those ofskill in the art.

The web server 704 is typically at least one computer system whichoperates as a server computer system and is configured to operate withthe protocols of the world wide web and is coupled to the Internet. Theweb server system 704 can be a conventional server computer system.Optionally, the web server 704 can be part of an ISP which providesaccess to the Internet for client systems. The web server 704 is showncoupled to the server computer system 706 which itself is coupled to webcontent 708, which can be considered a form of a media database. Whiletwo computer systems 704 and 706 are shown in FIG. 7, the web serversystem 704 and the server computer system 706 can be one computer systemhaving different software components providing the web serverfunctionality and the server functionality provided by the servercomputer system 706, which will be described further below.

Access to the network 702 is typically provided by Internet serviceproviders (ISPs), such as the ISPs 710 and 716. Users on client systems,such as client computer systems 712, 718, 722, and 726 obtain access tothe Internet through the ISPs 710 and 716. Access to the Internet allowsusers of the client computer systems to exchange information, receiveand send e-mails, and view documents, such as documents which have beenprepared in the HTML format. These documents are often provided by webservers, such as web server 704, which are referred to as being “on” theInternet. Often these web servers are provided by the ISPs, such as ISP710, although a computer system can be set up and connected to theInternet without that system also being an ISP.

Client computer systems 712, 718, 722, and 726 can each, with theappropriate web browsing software, view HTML pages provided by the webserver 704. The ISP 710 provides Internet connectivity to the clientcomputer system 712 through the modem interface 714, which can beconsidered part of the client computer system 712. The client computersystem can be a personal computer system, a network computer, a web TVsystem, or other computer system. While FIG. 7 shows the modem interface714 generically as a “modem,” the interface can be an analog modem, isdnmodem, cable modem, satellite transmission interface (e.g. “DirecPC”),or other interface for coupling a computer system to other computersystems.

Similar to the ISP 714, the ISP 716 provides Internet connectivity forclient systems 718, 722, and 726, although as shown in FIG. 7, theconnections are not the same for these three computer systems. Clientcomputer system 718 is coupled through a modem interface 720 whileclient computer systems 722 and 726 are part of a LAN 730.

Client computer systems 722 and 726 are coupled to the LAN 730 throughnetwork interfaces 724 and 728, which can be ethernet network or othernetwork interfaces. The LAN 730 is also coupled to a gateway computersystem 732 which can provide firewall and other Internet-relatedservices for the local area network. This gateway computer system 732 iscoupled to the ISP 716 to provide Internet connectivity to the clientcomputer systems 722 and 726. The gateway computer system 732 can be aconventional server computer system.

Alternatively, a server computer system 734 can be directly coupled tothe LAN 730 through a network interface 736 to provide files 738 andother services to the clients 722 and 726, without the need to connectto the Internet through the gateway system 732.

FIG. 8 depicts a computer system 740 for use in the system 700 (FIG. 7).The computer system 740 may be a conventional computer system that canbe used as a client computer system or a server computer system or as aweb server system. Such a computer system can be used to perform many ofthe functions of an Internet service provider, such as ISP 710 (FIG. 7).

In the example of FIG. 8, the computer system 740 includes a computer742, I/O devices 744, and a display device 746. The computer 742includes a processor 748, a communications interface 750, memory 752,display controller 754, non-volatile storage 756, and I/O controller758. The computer system 740 may be couple to or include the I/O devices744 and display device 746.

The computer 742 interfaces to external systems through thecommunications interface 750, which may include a modem or networkinterface. It will be appreciated that the communications interface 750can be considered to be part of the computer system 740 or a part of thecomputer 742. The communications interface can be an analog modem, isdnmodem, cable modem, token ring interface, satellite transmissioninterface (e.g. “DirecPC”), or other interfaces for coupling a computersystem to other computer systems.

The processor 748 may be, for example, a conventional microprocessorsuch as an Intel Pentium microprocessor or Motorola power PCmicroprocessor. The memory 752 is coupled to the processor 748 by a bus760. The memory 752 can be dynamic random access memory (dram) and canalso include static ram (sram). The bus 760 couples the processor 748 tothe memory 752, also to the non-volatile storage 756, to the displaycontroller 754, and to the I/O controller 758.

The I/O devices 744 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. The display controller 754 may control in theconventional manner a display on the display device 746, which can be,for example, a cathode ray tube (CRT) or liquid crystal display (LCD).The display controller 754 and the I/O controller 758 can be implementedwith conventional well known technology.

The non-volatile storage 756 is often a magnetic hard disk, an opticaldisk, or another form of storage for large amounts of data. Some of thisdata is often written, by a direct memory access process, into memory752 during execution of software in the computer 742. One of skill inthe art will immediately recognize that the terms “machine-readablemedium” or “computer-readable medium” includes any type of storagedevice that is accessible by the processor 748 and also encompasses acarrier wave that encodes a data signal.

Objects, methods, inline caches, cache states and other object-orientedcomponents may be stored in the non-volatile storage 756, or writteninto memory 752 during execution of, for example, an object-orientedsoftware program. In this way, the components illustrated in, forexample, FIGS. 1-3 and 6 can be instantiated on the computer system 740.

The computer system 740 is one example of many possible computer systemswhich have different architectures. For example, personal computersbased on an Intel microprocessor often have multiple buses, one of whichcan be an I/O bus for the peripherals and one that directly connects theprocessor 748 and the memory 752 (often referred to as a memory bus).The buses are connected together through bridge components that performany necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be usedwith the present invention. Network computers do not usually include ahard disk or other mass storage, and the executable programs are loadedfrom a network connection into the memory 752 for execution by theprocessor 748. A Web TV system, which is known in the art, is alsoconsidered to be a computer system according to the present invention,but it may lack some of the features shown in FIG. 8, such as certaininput or output devices. A typical computer system will usually includeat least a processor, memory, and a bus coupling the memory to theprocessor.

In addition, the computer system 740 is controlled by operating systemsoftware which includes a file management system, such as a diskoperating system, which is part of the operating system software. Oneexample of an operating system software with its associated filemanagement system software is the family of operating systems known asWindows® from Microsoft Corporation of Redmond, Wash., and theirassociated file management systems. Another example of operating systemsoftware with its associated file management system software is theLinux operating system and its associated file management system. Thefile management system is typically stored in the non-volatile storage756 and causes the processor 748 to execute the various acts required bythe operating system to input and output data and to store data inmemory, including storing files on the non-volatile storage 756.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present invention, in some embodiments, also relates to apparatusfor performing the operations herein. This apparatus may be speciallyconstructed for the required purposes, or it may comprise a generalpurpose computer selectively activated or reconfigured by a computerprogram stored in the computer. Such a computer program may be stored ina computer readable storage medium, such as, but is not limited to, anytype of disk including floppy disks, optical disks, CD-roms, andmagnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the methods of some embodiments. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language, and variousembodiments may thus be implemented using a variety of programminglanguages.

While this invention has been described by way of example in terms ofcertain embodiments, it will be appreciated by those skilled in the artthat certain modifications, permutations and equivalents thereof arewithin the inventive scope of the present invention. It is thereforeintended that the following appended claims include all suchmodifications, permutations and equivalents as fall within the truespirit and scope of the present invention; the invention is limited onlyby the claims.

1. A system, comprising: an object, including a first method with aninline reference; a state cache configured to invoke a second method,wherein when the first method is invoked the inline reference referencesthe state cache, which invokes the second method.
 2. The system of claim1, said object further comprising an inline cache, wherein the inlinecache includes the inline reference.
 3. The system of claim 1, saidstate cache further comprising an inline cache having computer codeassociated with the second method.
 4. The system of claim 1, furthercomprising a hash table of existing cache states.
 5. The system of claim4, wherein the hash table has a hash function of a class type and asignature of a method.
 6. The system of claim 4, wherein the object is afirst object, further comprising a second object without an inlinereference, wherein the hash table is used to speed up dynamic dispatchesfor the second object.
 7. The system of claim 1, wherein the object is afirst object, further comprising a second object without an inlinereference, wherein the second object invokes methods on objects ofvariable types.
 8. The system of claim 1, further comprising a pluralityof state caches, including the state cache, and a plurality of objects,including the object, wherein the number of cache states is less thanthe number of inline references.
 9. A system comprising: a state cache,associated with an object type; a plurality of methods with respectiveinline references to the state cache, wherein when a calling method ofthe plurality of methods is invoked, the calling method uses the inlinereference to reference the state cache, which invokes a called methodassociated with the object type.
 10. A process, comprising:instantiating an object, wherein the instance of the object includes afirst method having a dispatch point to a second method; invoking thefirst method; calling the second method at the dispatch point;intercepting the method call to the second method; determining state;adapting the first method to include at the dispatch point an inlinereference to a state cache associated with said state.
 11. The processof claim 10, wherein said state is associated with an object type and amethod signature, and wherein said object has the object type and thefirst method has the method signature.
 12. The process of claim 10,further comprising: creating the state cache; and associating the statecache with the second method.
 13. The process of claim 10, furthercomprising: searching existing state caches for the state cache, whereineach of the existing state caches is associated with a different state.14. A process, comprising: invoking a first method that includes aninline cache pointing toward a cache state; following the inline cacheto the cache state; invoking a second method from the cache state. 15.The process of claim 14, wherein the inline cache includes only areference to the cache state.
 16. The process of claim 14, furthercomprising performing method validation to ensure that state associatedwith the cache state is valid.
 17. The process of claim 14, wherein theinline cache is a first inline cache, further comprising: invoking athird method that includes a second inline cache pointing toward saidcache state; following the second inline cache to the cache state;calling the second method from the cache state.
 18. The process of claim14, further comprising initializing the first method by including theinline cache.
 19. The process of claim 14, wherein the inline cache isat a dispatch point, further comprising returning to the first methodafter the dispatch point.
 20. The process of claim 14, wherein the cachestate is a first cache state, further comprising: determining state; andupdating the inline cache to point toward a second cache state accordingto the determined state.